The mistery of the preprogrammed AVR fuses
Oh well, another week-end where things didn't really go as planned. But I made things work in the end.
So, the goal for friday evening was to assemble and test the final version of the Amstrad PCW keyboard to HID adapter I designed. The first version had a stupid mistake (I put the DIN connector backwards) and so I had to order a new batc of PCBs. On the first one I assembled, I was not able to program the microcontroller. So I assembled a second one, and hit the same problem. I did not spot any obvious assembly mistake (chip in the wrong orientation, short cicuits, ...) so I started suspecting a PCB design error. But, triple checking my schematics revealed nothing.
I started probing around with my scope, and quickly found that the quartz that is supposed to clock the circuit wasn't getting any movement. This circuit uses the AT90USB162 microcontroller, which is a bit special because it comes pre-flashed with an USB bootloader. For this to work, it requires an external clock, and the chips should be pre-configured to use a 8MHz quartz (what I have on the board). But, it seems they didn't.
The problem is, the ISP programming usually used to program these chips require the chip to have a working clock. Without one, the chip won't answer. The "proper" way to program these chips would be with a high voltage parallel programmer, but I don't have one that can accept these TAFP chips (especially not after they are already soldered onto a final PCB).
Before and after reaching to this conclusion, I did various experiments, one which involved trying to update the firmware on my USBASP (that I don't use much anymore, since I have an STK500 board) because avrdude complained that it couldn't control the SCK speed. That USBASP is one from Jyetech, and I noticed that it uses an ATMega48p, which is not one of the officially supported chips for the USBASP firmware. I tried flashing it with the ATMega48 version of the firmware and that bricked it.
I also tried ressurecting my older USBASP, one that I built myself with a PCB that was engraved by a local electronics shop near my parents home (yes, surprisingly they live in a relatively small city that somehow has TWO electronics parts shop, one of which would do PCB engraving, ROM programming, and other stuff on-demand, which was hugely convenient to me as a teenager trying to do electronics).
I put an ATMega8 back into that old thing, and got it back to the state it was when I last stopped using it: the USB interfacing works, but it does not detect the target device for some reason I can't find. And, more annoyingly, despite having the latest firmware, avrdude still complained that it couldn't configure the SCK speed.
Anyway, I figured out I should stop messing with these things and stick with the STK500 (and since we are talking about all my AVR programming tools: I got this one when a company I used to work for moved to a new office, and decided to throw away a bunch of unused equipment and parts). I wouldn't pay the full price for it, but it has been extremely useful.
Anyway, so, it looked like the chips were not getting any clock. I could think of two explanations: my quartzs were not working, or the chip were misconfigured. The first idea was easier to test: I put one of the quartz in the STK500 quartz socket, and could quickly confirm that it was generating a perfect 8MHz signal. So the quartz seemed OK. That left only the second option. Thinking about it, the obvious way to have one of these chips not clocked is to configure it to use an external oscillator instead of a quartz. All other settings would result in some sign of life at least.
Looking at my test crystal on the STK500 board, and re-reading the jumper settings and manual for the board, I realized that this quartz circuit on the STK500 is there precisely to help getting out of that situation: the board normally sends a clock signal to the chip being programmed (on one of its onboard sockets), so, even if the chip is set to use an external clock, it will work.
I added a wire to connect the oscillator output to the quartz on my board, and that was enough to get things going. I could finally reconfigure the fuses to the normal setting.
I was not fully out of trouble, however: some confusion resulted from using the online AVR fuse calculator, which somehow has the incorrect default values for the fuse bits for this chip? That was apparently copied into one of my makefiles, and I ended up setting the chip into an invalid state again. This time, my software was running, the clock was running, but still I wasn't able to change the fuses! Finally I managed to get out of this by shorting the HWB and RESET pins to ground, forcing the chip to enter bootloader mode. From there, I could flash a working version of my code. But I still had the wrong bootloader.
See, the idea with these adapters is that they are small. For this reason, I didn't want to include the HWB and RESET buttons as you'd normally do. Instead, the controller detects if a PCW keyboard is present, if not, it goes to firmware upgrade mode. This means the bootloader can be entered without any extra buttons.
Eventually I figured out what was happening (I think?). The chip was running, but the CLKDIV8 fuse was set, meaning it was running quite slow. This is fine for my code, but the ISP programming needs to be adjusted. To do this, one has to use the -B option to avrdude to force a slower clock. Doing that, I was finally able to flash my modified bootloader and get the thing working as I wanted.
Conclusion
I bought these chips back in 2021, during the parts shortage. At the time, they were out of stock on the usual suppliers and so I turned to utsource. This had two consequences: I have no idea where the chips actually come from, and, since I had to pay more for shipping than parts, I ordered a relatively large number (20 or so, more than I needed at the time).
What happened to these chips before I got them? I don't know. From the chips in this batch, a few were fine (the first 5 or so I used didn't give any problems), several but not all had the clock fuse problem, and at least one has a persistent write error in the flash.
My guess would be that these were chips that didn't pass tests at the factory, but with the parts shortage, someone decided to sell them anyway?
It is not the first time I run into problems with parts from UTSource, last time it was some GALs that I was not able to program at all. These came with stickers on top, meaning they were already programmed with something, but I think the offer on UTSource correctly listed them as used and I kind of accepted the risk.
Anyway, a weekend wasted in rescuing these chips, but it mostly worked in the end!
